OPC Studio User's Guide and Reference
OPC UA PubSub Descriptors
This article describes the descriptors used in OPC UA PubSub communication. For a relation between physical and logical identifiers and descriptors, see Identifying information in OPC UA PubSub.
In order to be able to describe how OPC Studio handles the logical and physical identifiers, especially in relation to OPC UA PubSub logical resolution, we need to define some terms first. There are also properties and methods that use these terms in their names, so knowing what they mean is beneficial to understand their purpose.
We say that a descriptor or filter strictly physical when it does not have a logical identifier in itself - that is, the name of the PubSub object is empty - and all its constituent descriptors (if there are any) are also strictly physical.
We say that a descriptor or filter requires resolution when an access to PubSub configuration is necessary in order to interpret the information in it for PubSub communication purposes. For example, a PubSub connection descriptor requires resolution when it has no (physical) network address specified, but it has a (logical) non-empty connection name. Similarly, a writer group descriptor requires resolution when its dataset writer Id is set to zero (i.e. "unknown"), but it has a (logical) non-empty dataset writer name, and so on.
A physicalization of a descriptor or filter is an operation that makes it strictly physical. A physicalization is only possible on descriptor or filters that currently do not require resolution. Physicalization is performed by setting the logical name of the object to an empty string, and physicalizing its constituent descriptors (if there are any).
A logicalization of a descriptor or filter is an operation that removes the physical information from it.
If you construct the descriptor with only the physical information, this physical information will be used to make the subscription. Analogically, if you construct the descriptor with only the logical information, this logical information will be used (resolved first, and if successful, the subscription will be made with the physical information yielded by the resolution). If, however, the descriptor contains both the physical and logical information (which is the case e.g. when the descriptor is obtained by browsing the PubSub configuration), the software is, in general, allowed to choose whether it will use the physical or logical information (the default behavior is that the physical information will be used). If you have a descriptor that can potentially contain both the physical and logical information, and you want to make sure that either one will be used for making the subscription, you can use the physicalization or logicalization operations to achieve that.
A PubSub connection descriptor combines together:
In order to specify a PubSub connection, you can set the PubSub connection name, or its network address, or both.
The PubSub connection can be "redirected" so that it uses a packet capture file, instead of true connection to the message oriented middleware (network). This is useful in all kinds of troubleshooting and development tasks. Such redirection is performed by setting up the PubSub connection descriptor in a specific way. For more information, see Using packet capture files with OPC UA PubSub.
Similar feature exists for broker-based communication. You can, for example, capture the received MQTT messages into a directory structure in the file system, and replay them later. For more information, see File-based MQTT emulation.
When possible, the transport profile (given by transport profile URI or transport profile name) is determined by OPC Studio, and you do not need to specify it explicitly. For more information on transport profiles, see OPC UA PubSub Transport Profiles.
In addition, for transport protocol mappings that are used with multiple message mappings (such as MQTT, which is used with JSON or UADP), QuickOPC supports special custom transport profiles that do not require you to know the message mapping upfront. For more information, see OPC UA PubSub Automatic Message Mapping Recognition.
The network address (in the NetworkAddress Property ) usually refers to the message oriented middleware. For example, for UDP, it can be an address of a UDP multicast group. For MQTT, it can be an address of an MQTT broker. There are, however, cases when the network address is set differently. For example, with UDP unicast, the network address is set to one of the local IP address of the computer that is receiving the messages, or to a local loopback address (using the "localhost").
A writer group descriptor combines together an optional logical writer group name with an optional writer group Id. That is, in order to specify a writer group, you can set the writer group name, or its Id, or both.
A dataset writer descriptor combines together an optional logical dataset writer name with an optional dataset writer Id. That is, in order to specify a dataset writer, you can set the dataset writer name, or its Id, or both.
The subscribe dataset filter is a kind of compound descriptor. It is documented separately in Message Filtering (OPC UA PubSub).
The dataset subscription descriptor combines the connection information (and communication parameters) with the subscribe dataset filter. Its structure is conceptually shown in the picture below.
The dataset subscription descriptor allows resolution if it has enough logical information specified to perform (or at least attempt) the resolution to the physical information necessary for actually making the subscription. This means that at least the published dataset name or the PubSub connection name must be given in the dataset subscription descriptor, for it to allow resolution.